Disable new test on clr interpreter#131139
Conversation
|
Azure Pipelines: Successfully started running 3 pipeline(s). 13 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Tagging subscribers to this area: @steveisok, @dotnet/area-system-diagnostics |
There was a problem hiding this comment.
Pull request overview
Adjusts System.Diagnostics.StackTrace async stack trace tests to avoid a failing scenario on the CoreCLR interpreter by isolating the problematic case into its own test and marking it with an interpreter-only skip.
Changes:
- Removes
ThrowsSoonValueTaskSourcefrom the shared async test data set used by the existing theory. - Adds a dedicated
[ConditionalFact]forThrowsSoonValueTaskSource, skipped on CoreCLR interpreter via[ActiveIssue].
|
@tommcdon Could you validate whether it is safe to bring back reporting for offsets without an empty stack, or whether we should do something else here, to model jit behavior. |
|
The fact that This mapping is also expected to have |
Test added in #130777.
For code like the one below, where the
GetResultof the value task source throws, the correct stacktrace should point to the await as the source of the throw. However, on interpreter, it is pointing to the new instruction.The cause of this seems to be that we only report IL->native offsets for locations where the IL stack is empty, therefore we don't have a location at the await. This seems to be easily fixable via BrzVlad@460eae9. The problem with the fix is that it is a partial revert of #127469 so it has a good chance to lead to regressions on other diagnostic tests.